1 Historical background
Within an enterprise, technology is deployed in layers over time. Many older technologies still bring value, making them far from obsolete. Consider that while many companies are undergoing digital transformation, the technology and related data contained in their old and deep layers is still valuable. They cannot simply be removed, as it is the underlying layer that will lay the foundation for the new post. Many of these layers often have legacy interfaces such as CORBA, RMI, SOAP, and so on.
So why do we continue to add layers on top of them? If we explore this issue as a paleontologist, we will collect a core sample and analyze each layer; we can also try this method for technology and go to various levels. Each layer represents a historical view. At the top / outermost layer, we can find REST, which is the most popular technology today. Just under REST, we encounter the Service Oriented Architecture (SOA) layer. Stop and think, why is REST replacing SOA? Although there are many reasons, it can be said that the main reason is that REST greatly simplifies the problem of client accessibility. With REST, you can exchange JSON instead of XML, which simplifies the use in the browser.
In addition, REST also has a simplified method, whose verbs GET, PUT, POST, etc. allow the use of simple general tools such as cURL and Postman. Creating your own client in almost any language is very easy.
2 On the other hand
Although the protocol is platform-independent, SOAP uses XML, which makes using it in a browser tedious and painful. In addition, the layer of complexity added by the WS- * standard means that writing the server side is easy, but writing the client side is painful. Client implementations need to use third-party tools to generate client code in the language of our choice, which can create heavy dependencies.
When we delve into the technology layer, we find a similar situation. SOAP was once the king, replacing technologies such as CORBA and RPC. REST has taken the throne from SOAP, and today, the throne of REST is being challenged by the voice of democracy.
Who is the challenger who can take the throne from REST? There are several people who are pursuing the throne of REST. These people can be divided into three categories: the "server-to-client", "event-based", or "data access" family. Just like in Game of Thrones, challengers can be divided by their family lineage (House Targaryen, House Lannister, House Stark, etc.)
3 The House of "Reverse API"
The hallmark of this family is the phone, which is the server calling the client and not the other way around.
Webhooks: Webhooks are sometimes referred to as "reverse APIs" because the originator of the call is the server, not the client; the server notifies the client of the state change. The client application registers a callback URL that can be accessed when the state of a resource on the server changes. Client applications will receive HTTP load notifications of status changes. Webhooks is a popular event-based mechanism that can be found online (GitHub, Stripe, Twilio). They are not silver bullets because they do not provide guaranteed delivery, rarely retry, may be out of sync, and put a lot of pressure on the client when the amount of events is large (backpressure mechanisms may be required).
WebSocket: WebSocket is a transport protocol that establishes a persistent two-way communication channel between the server and the client through a TCP socket connection. WebSocket is a good choice when server-to-client or client-to-server exchange is required in near real time. This overcomes the limitations of HTTP request / response mechanisms (such as client polling and associated overhead). WebSocket is suitable for applications that need to be updated in real time because the server can push data on the connection at any time. All modern browsers support WebSocket.
SSE: Server-Sent Events (SSE) is a server push technology that allows clients to receive automatic updates from the server over an HTTP connection with a built-in automatic reconnection mechanism. The Server Send Event EventSource API is standardized as part of HTML5. SSE is sent over traditional HTTP, which means that it does not require special protocols or server implementations to work properly. WebSockets, on the other hand, require full-duplex connections and new Web Socket services to handle the protocol. SSE is suitable for scenarios that do not need to send data from the client, but need to be updated through certain server operations (such as stock quotes, shared facility updates, friend status updates, etc.).
4 The House of "Event-Driven"
The logo of this family is the Kafka icon because it is the "event-driven" leader.
This home consists mainly of three characters, two messaging systems based on commit logs Apache Kafka and NATS, and RabbitMQ's message queue. These technologies have become practical pillars of microservice architectures based on asynchronous events. Event messaging-based architecture results in extremely loose coupling between services, which is useful for event-driven systems. In these architectures, different design patterns such as CQRS (command query separation of duties) and event sources are very popular. Because JSON is too verbose, messages sent to the queue are defined using Proto Buf, Avro, or Thrift, and events will be consumed by internal microservices.
Because event-based systems are asynchronous, the system itself will be ultimately consistent. This causes developers to have to deal with inconsistent data between services. Depending on the messaging backbone used, you may have to consider the processing of receiving duplicate events, out-of-order events, or missing events (guaranteed delivery). Compared to traditional REST APIs, the tools available for event-based development (design, debugging, testing, monitoring) are more immature.
There are two emerging projects worth tracking and investing in:
-
The CloudEvents project, incubated by the Cloud Native Foundation (CNCF), is trying to define vendor-independent event formats in order to convert between different cloud systems.
-
The goal of the AsyncAPI is to make event-driven architectures simpler and as familiar to developers as REST APIs, it will include documentation, code generation, discovery, and event management.
5 ThegRPC family The House of gRPC
There are clues in the name of gRPC; the "g" comes from Google and RPC because it is designed for remote procedure call (RPC). This is a top-level project of CNCF. gRPC is often used internally within an organization (that is, in a microservices architecture) so that we can control consumers and providers. Because it uses HTTP 2.0, gRPC has higher performance than traditional HTTP 1.1 REST calls. The service definition uses Proto Buf, so client and server stubs can be generated in multiple languages. gRPC supports two-way streaming and pluggable authentication mechanisms.
6 "GraphQL" family The House of "GraphQL"
GraphQL: The GraphQL API is suitable for mobile applications and helps avoid gossip issues when using the REST API. With GraphQL, clients can determine what data they need, what kind of data they need, and the data format they need without having to traverse multiple REST requests / responses to find the resources required by the application. This will reduce the number of network connections required to invoke the client and ensure that they retrieve only the data they need. If the client is a mobile application or a single-page application (SPA), it can provide a better user experience. In 2015, Facebook publicly released the GraphQL specification and reference implementation. But today, GraphQL is managed by the GraphQL Foundation.
Further reading: Why is GraphQL the future of API?
7 The House of "OData"
OData: OData (Open Data Protocol) is an OASIS standard that defines best practices for building and using RESTful APIs. It was originally developed by Microsoft in 2007. OData is a common set of conventions over HTTP, REST, and JSON. If these conventions are adopted, it means that API providers will eventually deal with issues such as querying, pagination, sorting, and filtering APIs in a standard and consistent way. Because of these conventions, if we see an OData service, then we also see all the services, and it becomes easier to implement consumer applications. OData APIs often appear in ecosystems running Microsoft and SAP services.
8 The House of "IoT" family
Given the explosive growth of IoT devices, the family is firmly anchored in the Billionaires Club.
MQTT (Message Queue Telemetry Transmission): is a publish-subscribe based ISO standard messaging protocol. It works on top of the TCP / IP protocol. It is designed for connection to remote locations that require "small code footprint" or in situations where we need to limit network bandwidth. Therefore, it is a perfect protocol for clients such as embedded systems with expensive bandwidth and minimal overhead.
AMQP (Advanced Message Queuing Protocol) is one of the most popular protocols in asynchronous communication. RabbitMQ and ActiveMQ are some popular implementations, or there are hosted solutions like AWS MQ. AMQP is an open standard application layer protocol for message middleware. The main characteristics of AMQP are message orientation, queuing, routing, reliability, and security. AMQP has more features than MQTT, so it is better suited to run on client systems that require higher processing and memory requirements. As such, it is considered a rather heavy protocol that does not work well in the sensor / embedded world of the Internet of Things.
9 Conclusions
As this article shows, the monarchy of REST API / Services has passed. The required API technology ecosystem will be dedicated to the needs of consumer client applications. There will not be only one winner in the ecosystem, but many winners, depending on the experience required by the customer. No technology will always sit on the throne. This is a democracy, and customers decide who will represent them!
APIs are dead-Long live APIs!
1 歷史背景
在一個企業內部，隨著時間的推移，技術會分層部署。許多較老的技術仍然能帶來價值，使其遠未過時。考慮到儘管許多企業正在經歷數字化轉型，但它們的舊層和深層中所包含的技術和相關數據仍然具有價值。不能簡單地將它們移除，因為畢竟是在下面的層才能為放置新柱子奠定基礎。這些層中的許多通常都具有遺留接口，如CORBA、RMI、SOAP 等。
那麼，為什麼我們要在層上繼續添加層呢？如果以古生物學家的身份來探討這個問題，我們會採集一個核心樣本，分析每一層；針對技術也可以來嘗試這個方法，並深入到各個層次。每一層都代表一個歷史視圖，在最頂層/ 最外層，我們可以找到REST，它是當今最普及的技術。就在REST 之下，我們會遇到面向服務架構（Service Oriented Architecture，SOA）層。停下來思考下，為什麼REST 取代了SOA ？雖然原因有很多，但可以說最主要的原因是REST 極大地簡化了客戶端可訪問性的問題，使用REST，可以交換的是JSON 而不是XML，從而簡化了在瀏覽器中的使用。
此外，REST 還有一個簡化的方法，其動詞GET、PUT、POST 等允許使用簡單的通用工具，比如cURL 和Postman。幾乎用任何語言創建自己的客戶端都非常簡單。
2 另一方面
雖然該協議與平台無關，但是SOAP 使用XML，這使得在瀏覽器中使用它變得冗長而痛苦。此外，由WS-* 標準增加的複雜性層意味著編寫服務器端很容易，但編寫客戶端卻很痛苦。客戶端實現需要使用第三方工具以我們所選擇的語言來生成客戶端代碼，這會產生繁重的依賴關係。
當我們深入研究技術層時，我們會發現類似的情況。SOAP 曾經也是王者，它取代了CORBA 和RPC 等技術。REST 從SOAP 那里奪走了王位，而今天，REST 的王位正受到來自民主呼聲的挑戰。
誰是能從REST 手中奪取王位的挑戰者呢？有幾個有追求的人在覬覦REST 的王位。這些人可以分為三類：“服務器到客戶端”、“基於事件”或“數據訪問”家族。就像在《權力的遊戲》中一樣，挑戰者可以按照他們的家族血統來劃分（House Targaryen、House Lannister、House Stark 等）
3 “反向API”家族The House of "Reverse API"
這個家族的標誌是電話，既是服務器調用客戶端，而不能反過來調用。
Webhooks： Webhooks有時被稱為“反向API”，因為調用的發起方是服務器而不是客戶端；服務器將狀態變更通知客戶端。客戶端應用程序註冊一個回調URL，當服務器上的資源發生狀態變更時，就可以訪問該URL。客戶端應用程序將收到狀態變更的HTTP負載通知。Webhooks是一種流行的基於事件的機制，該機制可以在網上找到（GitHub、Stripe、Twilio）。它們不是銀彈，因為它們不提供有保證的交付，很少重試，可能會不同步，並且在事件量很大時（可能需要反壓機制）會給客戶端帶來很大的壓力。
WebSocket： WebSocket是一種傳輸協議，它通過一個TCP套接字連接在服務器和客戶端之間建立一個持久的雙向通信通道。當服務器到客戶端或客戶端到服務器需要近實時交換時，WebSocket是一個不錯的選擇。這克服了HTTP請求/響應機制的限制（例如客戶端輪詢及相關的開銷）。WebSocket適用於需要實時更新的應用程序，因為服務器可以在連接上隨時推送數據。所有現代瀏覽器都支持WebSocket。
SSE：服務器發送事件（Server-Sent Events，SSE）是一種服務器推送技術，它允許客戶端通過帶有內置自動重連機制的HTTP連接接收來自服務器的自動更新。服務器發送事件EventSource API作為HTML5的一部分被進行了標準化。SSE是通過傳統HTTP發送的，這意味著它不需要特殊的協議或服務器實現即可正常工作。另一方面，WebSockets需要全雙工連接和新的Web Socket服務來處理協議。SSE適用於不需要從客戶端發送數據，但需要通過某些服務器操作進行更新（例如股票行情、共享設施更新、好友狀態更新等）的場景。
4 “事件驅動”家族The House of "Event-Driven"
這個家族的標誌是Kafka 圖標，因為它是“事件驅動”的主導者。
這個家主要由三個字符組成，即兩個基於提交日誌Apache Kafka 和NATS 的消息傳遞系統，以及RabbitMQ 的消息隊列。這些技術已經成為基於異步事件的微服務架構的實際支柱。基於事件消息傳遞的架構會導致服務之間的極度鬆散耦合，這對於事件驅動系統非常有用。在這些架構中，諸如CQRS（命令查詢職責分離）和事件源等不同的設計模式非常流行。因為JSON 太冗長，發送到隊列的消息使用Proto Buf、Avro 或Thrift 定義，事件將被內部微服務消費。
由於基於事件的系統是異步的，因此系統本身將具有最終一致性。這導致開發人員不得不處理服務之間的不一致數據。根據所使用的消息傳遞主幹，可能必須考慮接收重複事件、無序事件或丟失事件（保證交付）的處理。與傳統的REST API 相比，可用於基於事件的開發（設計、調試、測試、監控）工具更加不成熟。
有兩個新興項目值得跟踪和投入：
-
由雲原生基金會（Cloud Native Foundation，CNCF）孵化的CloudEvents 項目正在嘗試定義與供應商無關的事件格式，以便在不同的雲系統之間進行轉換。
-
AsyncAPI 的目標是使事件驅動的架構更簡單，並且像REST API 一樣為開發人員所熟悉，它將包括文檔、代碼生成、發現和事件管理。
5 gRPC家族The House of gRPC
gRPC 的名稱中包含了一些線索；“g” 來自Google 和RPC，因為它是為遠程過程調用（RPC）而設計的。這是CNCF 的一個頂級項目。gRPC 通常在組織內部使用（即在微服務架構中），這樣我們可以控制消費者和提供者。因為它使用了HTTP 2.0，gRPC 相較於傳統的HTTP 1.1 REST 調用有較高的性能。服務定義是使用了Proto Buf ，由此，可以用多種語言生成客戶端和服務端存根。gRPC 支持雙向流和可插拔的身份驗證機制。
6 “GraphQL”家族The House of "GraphQL"
GraphQL： GraphQL API適用於移動應用程序，並且有助於避免使用REST API時出現的閒聊問題。借助GraphQL，客戶端可以確定它們所需的數據、所需怎樣的數據以及所需的數據格式，而無需遍歷多個REST請求/響應來查找應用程序所需的資源。這將減少調用客戶端所需建立的網絡連接次數，並確保它們只檢索所需的數據。如果客戶端是移動應用程序或單頁應用程序（single-page application，SPA），則可以提供更好的用戶體驗。2015年，Facebook公開發布了GraphQL規範和參考實現。但今天，GraphQL的管理工作由GraphQL基金會負責。
延展閱讀：為什麼說GraphQL是API的未來？
7 “OData”家族The house of "OData"
OData： OData（開放數據協議）是一個OASIS標準，它定義了構建和使用RESTful API的最佳實踐。它最初是由微軟在2007年開發的。OData是HTTP、REST和JSON之上的一組通用約定。如果採用這些約定，則意味著API提供者最終將以一種標準且一致的方式來處理諸如查詢、分頁、排序和過濾API之類的問題。正是由於這些約定，如果我們看到了一個OData服務，那麼我們也就看到了所有服務，並且實現消費應用程序變得更加容易。OData API經常出現在運行Microsoft和SAP服務的生態系統中。
8 “IoT”家族The House of "IoT"
鑑於物聯網設備的爆炸性增長，這個家族牢牢地坐落在億萬富翁俱樂部裡。
MQTT（消息隊列遙測傳輸）：是一種基於發布-訂閱的ISO標準消息傳遞協議。它在TCP/IP協議之上工作。設計它是用於與需要“小代碼佔用”的遠程位置的連接或我們需要限製網絡帶寬的情況。因此，對於帶寬昂貴且所需開銷最小的嵌入式系統等客戶端來說，它是一種完美的協議。
AMQP（高級消息隊列協議）是異步通信中最流行的協議之一。RabbitMQ和ActiveMQ是一些流行實現，或者有像AWS MQ這樣的託管解決方案。AMQP是面向消息中間件的開放標準應用層協議。AMQP的主要特點是消息定向、排隊、路由、可靠性和安全性。與MQTT相比，AMQP具有更多特性，因此，它更適合在需要更高處理和內存要求的客戶端系統上運行。因此，它被視為一個相當繁重的協議，在物聯網的傳感器/嵌入式世界中不能很好地發揮作用。
9 結論
正如本文所示，REST API /Services 的君主統治已經過去了。所需的API 技術生態系統將專用於消費客戶端應用程序的需求。生態系統中不會只有一個贏家，而是有許多贏家，這取決於客戶所需的經驗。沒有一項技術會永遠坐上王位上，這是一種民主，客戶決定將由誰來代表他們！
API 已死了——APIs 萬歲！